Date: Sun, 28 Nov 93 04:30:14 PST 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V93 #126 

To: Ham-Digital 


Ham-Digital Digest Sun, 28 Nov 93 Volume 93 : Issue 126 


Today's Topics: 
ATM on Amateur Radio? 
Ham Radio - Internet gateway 
wb7tpy gateway (3 msgs) 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Sat, 27 Nov 1993 21:38:26 GMT 

From: swrinde! gatech!udel!darwin.sura.net!ra!atkinson@network.ucsd.edu 
Subject: ATM on Amateur Radio? 

To: ham-digital@ucsd.edu 


In article <CHOn75.CM2@cunews.carleton.ca> im@hydra.CARLETON.CA (Ian McEachern 
VE3PFH) writes: 


>First off there is nothing saying that Amateur Radio ATM will need 
>26 Mbps, or anything on that order to do something usefull. 


No, but the overhead due to ATM cell size and header structure is 
high. On top of that, one has ATM Adaptation Layer overhead (again 
not trivial) and then one has to have some way to format the user 
data. This WILL consume much more bandwidth than is taken up at 
present. 


>The telco standards people are looking to map ATM cells onto T1 
>carriers right now, and when that is done there is talk that 
>they'1l map ATM cells onto DSO's too! 


None of which means that it makes any sense, particularly from a 
bandwidth perspective. IP/T3 has much more useful bandwidth than 
IP/ATM/T3. The same is true whether one has T3 or T1 or DSO or 
some lower bandwidth. 


>Secondly there could be some interesting benefits to a Ham implementation 
>of ATM. Can you imagine a data standard that could pass both voice, data 
>and video with appropriate handling? 


IP can do this today over low-bandwidth channels. With the 
implementation and deployment of real-time flow support and resource 
reservation (e.g. as proposed in the RSVP protocol specification), it 
should be even better suited for this. Of course, ATM is much more 
sexy to talk about even if it isn't as good a solution technically... 


>Expand your mind abit further and imagine an ATM switch on the Phase 4 
>Ham satellite, to switch your packets quickly over to the beam 

>on europe, to download the latest version of GRINOS, while simultaneously 
>enjoying a ragchew with a group of VK's in the outback, through 

>the beam pointed towards Auz. 


ATM switches have real problems with cell loss and congestive 
collapse. The features that you describe all are a function of the 
bandwidth available much more than which link protocol (ATM is after 
all a kind of link/subnet protocol) is in use. ATM is a very high 
overhead approach to those problems. Running normal IP would be a 
much more appropriate solution. 


>I think the big benefit of something like ATM will be integrating 
>voice and data in the ham world! 


IP can do this now with less bandwidth than ATM would require. The 
machines on my desk move audio, video, and data between three 
continents in real-time just fine, sharing bandwidth with ftp and 
telnet and smtp sessions. One can't do it very well at 9600 baud with 
ANY technology though. Compressed voice and full-motion video still 
require a whole lot of bandwidth by Ham standards. 


ATM is mostly hype at this point, consider what the ATM specifications 
really say before claiming that ATM is a likely solution to any problem. 
In general, the Ham community garnered its good reputatioin by applying 
science to its problems. Let's keep up that tradition. 


Date: 25 Nov 1993 06:45:56 GMT 
From: koriel!sh.wide!wnoc-kyo!daemun.rcac! reseau! kenji@ames.arpa 


Subject: Ham Radio - Internet gateway 
To: ham-digital@ucsd.edu 


In article <rcrw90-231193082417@node_13059.aieg.mot.com> rcrw90@email.mot.com 
(Mike Waters) writes: 
|In the US a packet message is "third party traffic" for the relaying 
|stations no matter xwhox originates it. If a ham originates the message 
|then only the link from the first station to the BBS or relay is non "third 
|party". 


You're right. Maybe not only in the USA. 


|On the other hand ham radio can well be used to supplement other services. 
|Emergency response is one of the most obvious of these. 


I also want to emphasize this point - 


|Personally I think we should be able to carry much of Netnews via ham radio 
|for example (or at least FIDO!). As far as I know that is not done today. 


We're running our own NetNews groups in Japanese called ampr.*. There 
are some other local newsgroups here. 


|There are Internet/PBBS gateways for E-mail though, although they tend to 
|be somewhat awkward to use. 


Quite a few PBBS operators in Japan do not want to see messages of 
non-licensees. I am against this attitude so I don't run nor recommend 
people to run PBBS nodes. 


|Another use I have seen is for a yacht in the South Pacific to submit an 
|article via packet to a (nonprofit) club magazine in Ft. Lauderdale. 
|Appeared to work very well and was much faster than the mail in that part 
|of the world. 


A practical use of ham radio - ham radio people must support 
non-profit activities, I believe. Otherwise, airwave bandwidth for ham 
radio people should be reallocated for other public services. 


// Kenji 
Kenji Rikitake <kenji@k2r.or.jp> <kenji@rcac.astem.or.jp> (More available!) 
Persuade me you may, but I won't be persuaded. -- Aristophanes 


Date: 25 Nov 1993 06:54:22 GMT 
From: koriel!sh.wide!wnoc-kyo!daemun.rcac! reseau! kenji@ames.arpa 


Subject: wb7tpy gateway 
To: ham-digital@ucsd.edu 


In article <2d08eo$mi4@wvhpadm1.mentorg.com> hanko@wv.mentorg.com (Hank Oredson) 
writes: 

|The real problem here is that the inter-network router somehow "forgot" 

|that BBS network domains have an implied “ampr.org" at the end of them. 

[As in wOrli@wOrli.or.usa.na.ampr.org ... 


It's all up to ampr.org domain administrator (namely Brian Kantor) to 
accept this or not. 


// Kenji 
Kenji Rikitake <kenji@k2r.or.jp> <kenji@rcac.astem.or.jp> (More available!) 
Persuade me you may, but I won't be persuaded. -- Aristophanes 


Date: 25 Nov 1993 06:51:58 GMT 

From: koriel!sh.wide!wnoc-kyo!daemun.rcac! reseau! kenji@ames.arpa 
Subject: wb7tpy gateway 

To: ham-digital@ucsd.edu 


In article <2ctoto$h25@wvhpadm1.mentorg.com> hanko@wv.mentorg.com (Hank Oredson) 
writes: 
|What routing information? 


The requirement of including regional/geographic information into the 
mailing address. This will not work. 


|These are NOT routes we are talking about ... 
|they are locations ... 


Locations are geographic information :) 


|I think all the bbs authors understand that a location is 
|not a route, and address is not a route nor a location, 
Jetc. etc. 


People tend to interpret location info can be used for routing. This 
doesn't work. See "The Internet Message - Closing The Book with 
Electronic Mail", by Marshall T. Rose for how OSI X.400 failed by not 
specifying resolution mechanism between addresses and routes. 


// Kenji 


Kenji Rikitake <kenji@k2r.or.jp> <kenji@rcac.astem.or.jp> (More available!) 
Persuade me you may, but I won't be persuaded. -- Aristophanes 


Date: 25 Nov 1993 06:59:56 GMT 

From: koriel!sh.wide!wnoc-kyo!daemun.rcac! reseau! kenji@ames.arpa 
Subject: wb7tpy gateway 

To: ham-digital@ucsd.edu 


In article <2ctpip$h25@wvhpadm1.mentorg.com> hanko@wv.mentorg.com (Hank Oredson) 
writes: 

|If people would simply STOP trying to connect the two networks, 

|the problem would just go away. 


I disagree. At least some part of ham radio community want to 
communicate with Internet. And I see no ethical issues on connecting 
these networks, although laws must be changed. 


|Now folks want to connect them. 

yes. 
|There is certainly no problem creating some new top level domain 
|for the bbs network - but why bother? We have one already: it 
|is ampr.org ... so what is the problem with using that at the gates? 
|Anything that came from the bbs net gets appended .ampr.org when it 
|moves to the internet. Same thing the other way: the .ampr.org gets 


|dropped once the traffic is inside that net. 


In near future PBBS systems should be re-written to keep ampr.org 
INSIDE the network. Mail addresses should be treated as is. 


|Is there some problem with this concept? 
I think it's ok as long as ampr.org domain administrator agrees. 
|wOrli@wOrli.or.usa.noam.ampr.org - no big deal for any router to handle. 
No. :) 
|Oh yes, I know about the issues with tcp/ip - but tcp/ip within the bbs net 
lis yet a different issue. One still needs the hierarchical location 
|information, since many services do indeed use those identifiers as routing 
|hints (ROUTING HINTS, not ROUTES ...) and we would like to continue to do 


|so. 


Well, in fact. parsing identifiers to obtain routing information is 


acceptable. 


// Kenji 
Kenji Rikitake <kenji@k2r.or.jp> <kenji@rcac.astem.or.jp> (More available!) 
Persuade me you may, but I won't be persuaded. -- Aristophanes 


Date: 23 Nov 93 16:35:18 CST 
From: timbuk.cray.com!hemlock.cray.com!andyw@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <KENIJI.93Nov21192404@reseau.k2r.or.jp>, 
<2cp3dk$lls@unicorn.ccc.nottingham.ac.uk>, <2ctp3q$h25@wvhpadm1.mentorg.com> 
Subject : Re: wb7tpy gateway 


In article <2ctp3q$h25@wvhpadm1.mentorg.com>, hanko@wv.mentorg.com (Hank Oredson) 
writes: 

> Levee] 

And that Namibia is in Africa and not in North America. 

And is never addressed with one of those really stupid internet 

TWO letter designations. At least we got one thing right in 

the bbs network: we used the THREE letter country codes ... 


VVNV WV 


Err, the site that ended up with a pile of xxx.usa.na messages 
was in Namibia, and it's official domain name xdid* end in .na 
Actually, since the guy had to pay for all those messages to 
get delivered over a long distance UUCP connection, and then 
pay again while they bounced (until he at least stopped that), 
I thought he was more than reasonable about the whole affair... 


> And any reasonable router should be able to tell the difference 
> between USA.NA and something in Namibia - or does Namibia have 
> a USA sub-domain ? 

And here we have it, the "left to right" parsing thinking that 


brought you the # fields in PBBS addresses. If someone wants 
to call a domain in Namibia "usa" then they are entitled to. 


Sigh.. 
andyw NOREN/G1XRL 


andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 


Date: Sat, 27 Nov 1993 21:25:15 GMT 

From: swrinde! gatech!europa.eng.gtefsd.com!paladin.american.edu!darwin.sura.net! 
ra!atkinson@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <CGrL57.6Iq@usenet.ucs.indiana.edu>, 
<1993Nov22.191806.11611@hplabsz.hpl.hp.com>, <2ctnrt$ocf@newsserv.cs.sunysb.edu> 
Subject : Re: ATM on Amateur Radio? 


In article <2ctnrt$ocf@newsserv.cs.sunysb.edu> rick@cs.sunysb.edu (Rick Spanbauer) 
writes: 


> You're confining yourself with how ATM might apply to 

> existing amateur packet. Bandwidth allocation similar 
> to ATM might make sense in a full duplex system where a 
> hub would have to decide how to split up its forward 

> channel bandwidth among the client nodes. 

> 

> Rick Spanbauer, WB2CFV 

ATM/RF doesn't make much sense. We've been looking into it for 
hypothetical use with Navy radios and very rapidly concluded that 
ATM/RF lost big. If even one ATM cell has a bit error at the 
receiver, the entire AAL frame has to be retransmitted. Consider that 
IP/AAL5 uses 9180 as the MTU size, that there are 48 octets of user 
data per 53 octet ATM cell, that the typical bit error rate of an RF 
channel is high, and the bandwidth costs of solid ECC. By contrast, 
IP/RF works reasonably well and is currently used by a large number of 
non-commercial, commercial and government users. 


A lower overhead and technically superior solution for bandwidth 
reservation would be to use a resource reservation protocol 

(e.g. RSVP, which is being proposed for use with IP). ATM doesn't 
handle bandwidth reservation very effectively -- though the marketing 
droids tout bandwidth reservation as an advantage. 


ATM also has potentially severe problems with switch congestion and 
cell loss. The main way that real ATM users are coping with this 
switch problem is the traditional telco solution (over-engineer the 
network big-time) and this is expensive to do. 


In short, wise folks will soon understand that ATM is mostly hype at 
this point, that it is NOT a panacea, and that it probably can't be 

usefully extended very far outside its design objective (connecting 

fiber optic circuits together for telephone companies and for high- 

bandwidth fiber-optic computer communications circuits). 


Ran 

atkinson@itd.nrl.navy.mil 

(who until very recently was working on ATM full-time) 
employed by, but not speaking officially for the 

Information Technology Division, Naval Research Laboratory... 


Date: 25 Nov 1993 11:28:14 -0000 

From: pipex!uknet! warwick! unicorn.nott.ac.uk!unicorn.nott.ac.uk!not-for- 
mail@uunet.uu.net 

To: ham-digital@ucsd.edu 


References <2ctp3q$h25@wvhpadm1.mentorg.com>, 
<1993Nov23.163518.13551@hemlock.cray.com>, <2d08eo$mi4@wvhpadm1.mentorg.com>k 
Subject : Re: wb7tpy gateway 


In article <2d08eo$mi4@wvhpadm1.mentorg.com> Hank_Oredson@mentorg.com writes: 
>In even simpler terms: once the application has parsed off the 

>very last field (NA) and then looks at the next field (USA), it 

>can certainly notice that there ARE no sub-domains USA.NA in 

>Namibia ... or is the Internet addressing scheme to stupid to 

>allow for things like this? 

A quick DNS trawl courtesy of nslookup reveals: 


na. SOA train.psg.com hostmaster.ns.psg.com. (9307100 
345600 7200 2592000 691200) 
(snip) 
na. MX 10 kudu.ru.ac.za 
na. MX 20 hippo.ru.ac.za 
na. MX 100 rip.psg.com 
na. MX 150 m2xenix.psg.com 
* MX 10 kudu.ru.ac.za 
* MX 20 hippo.ru.ac.za 
* MX 100 rip.psg.com 
* MX 150 m2xenix.psg.com 


So, all mail to Namibia should go through South Africa anyway. What happens 
then depends on what ru.ac.za does with it.. hopefully, it'd be sensible enough 
to bounce anything @n9zzz.#zz.usa.na. If it doesn't, something's broke 
somewhere. . 


Mike 
+- Mike Knell, University of Nottingham, UK -=- M.Knell@unicorn.nott.ac.uk --+ 


| --THIS SPACE TEMPORARILY BLANK-- | AMPR: g7gpa@hobbes.g7gpa.ampr.org | 
| (until I can think of a decent joke)| AX25: g7gpa@g7gpa.gb7bad.#23.gbr.eu_ | 


|UNDER the overpass! OVER the underpass! Around the future and BEYOND REPAIR! | 


End of Ham-Digital Digest V93 #126 
KKKKKKKKKKKKKKKKKKKKKEKKEKRKR KAKI 
KKKKKKKKKKKKKKKKKKKKKKKKEKRKE KAKA 


